[セッションレポート] ワーナーBros. DiscoveryはどのようにしてAWSの運用効率を高めたか? (COP201)

[セッションレポート] ワーナーBros. DiscoveryはどのようにしてAWSの運用効率を高めたか? (COP201)

Amazon Managed Grafanaを中心にPrometheusやOpenTelemetryを駆使してAWS環境の可観測性をあげたよ、という事例セッションを聴講しましたのでレポートします。
Clock Icon2022.12.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

概要

映像制作から配信まで抱える巨大なコンテンツ企業・ワーナーブラザーズ。そのシステムの運用・監視体制をどう見直したか、という事例セッション「 How Discovery increased operational efficiency with AWS observability 」を聴講しましたので、簡単にレポートします。業界に特化しない汎用的な事例として、とても参考になるセッションでした。

In this session, hear how Discovery has modernized their observability platform by building a cohesive centralized platform on AWS to manage the ingestion, processing, retention, metering, analysis, visualization, and governance of operational data such as logs, metrics, and tags. Additionally, learn how to build a large-scale observability platform on AWS that improves developer experience, increases flexibility, and helps improve organizational fiscal responsibility.

TL;DR

  • 多種多様だったツールや運用手順・データ形式を最小限にまとめる
  • 全てGrafanaに集めて関係各署用のダッシュボードを作成
  • コスト監視にはkubecost
  • 汎用的な監視セット:metrics-as-a-serviceとlogging-as-a-service
  • 「出来合いの(out-of-the-box)」ソリューションを選択、車輪の再発明を抑えよう

内容

  • Warner Bros. Discovery
    • 「TV・映画・ネット配信向けの、世界でもっとも多種多様なコンテンツを擁するエンタテインメントカンパニー」
    • DCコミック映画
    • 配信プラットフォーム「HBO MAX」
  • オブザーバビリティとは?
    • 不知の不知
    • メトリクス・ログ・トレース
    • デバッグの先にあるもの
  • WSDのオブザーバビリティ化は 2021 年から開始
  • スタート時点での状況
    • エコシステム(使っている技術)の不一致
    • 運用データの標準化が最小限
    • スケーラビリティに問題
  • 最終的な到達点(ゴール)
    • エコシステムの機能的な階層を定める
    • 全ての運用データを、その階層の要素と位置づける

運用メタデータ(OMD)

  • Operational metadata (OMD) = 監視データの標準化
  • そうすることで、以下を統一化できる
    • ツール
    • 検索方法
  • AWS Service Catalogを使って画一的な環境を構築

ツールの話

  • ダッシュボード : Grafana (Amazon Managed Grafana/AMG)
  • メトリクス : Prometheus (Amazon Managed Services for Prometheus/AMP)
  • ログ : Amazon OpenSearch Service
  • トレース : Jaeger, Zipkin
  • ADOT (AWS Distro for OpenTelemetry)をコレクターとして使用
  • なぜAWSマネージドなOSSを使うのか?
    • メンテナンス・セキュリティ
    • 本番ワークロードで使える
    • AWSとのシームレスな連携
    • コミュニティへの還元も

それで、どうなった?

  • AMPはSOCやISOに準拠している、AMGはVPC内のリソースに安全に接続可能
  • AMPもAMGもスケールする
  • ダッシュボードの集約もできた
  • logging-as-a-service
    • FluentD --> Kinesis Data Firehose
      • --> OpenSearch Service (検索用)
      • --> S3 (保存用)

  • metrics-as-a-service
    • ADOTエージェント --> AMP
      • Grafana ダッシュボード
      • Promxyによる複数Prometheusの一括検索

  • それらによる効果
    • 収集データ量 : 2倍(6TB/日 --> 12TB/日
    • 1日に生成されるメトリクス数 : 730万

このあとは?

  • ログからメトリクスを生成(log-to-metrics)
  • コスト監視
  • トレースもOpenTelemetryに
  • Amazon OpenSearch Serviceの最適化
  • 複数のテナントにまたがるリソースに対する計測

参考

所感とまとめ

PrometheusとGrafanaを核とした監視システムというのは、ある意味鉄板の構成です。でもそうでありながら、「なぜその選択をしたのか」「どういうところを考慮したのか」を丁寧に説明していただけた貴重なセッションでした。
AMP・AMGを使うかどうかに関わらず、なぜか社内の監視システムがしっくりこない・これから整理しようとしているかたには参考になると思います。是非ご覧ください。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.